Dyad Health ← Back to home
Explainer

What is FHIR,
and why does it matter?

A plain-English guide to the data standard that's about to reshape prior authorization — and why being FHIR-native from day one is structural advantage, not marketing.

Last updated April 2026 · Written for health plans, providers, and curious families

§ 01The short version

FHIR (pronounced "fire") stands for Fast Healthcare Interoperability Resources. It's a standard, published by HL7 International, for how health systems exchange clinical data — problems, medications, lab results, care plans, encounters, prior-authorization requests — in a modern, web-friendly format.

The previous generation of health data exchange was built on fax machines, PDFs, and 1990s-era HL7 v2 messages. FHIR replaces that with structured, machine-readable resources (Patient, Observation, MedicationRequest, Claim, and about a hundred others) that software can query, validate, and respond to in real time.

If you remember one thing: FHIR is the difference between a health plan receiving a 40-page PDF that has to be read by a human, and receiving a structured packet of clinical facts a system can evaluate instantly.

§ 02Why this is suddenly urgent

On April 8, 2026 the Centers for Medicare & Medicaid Services' Interoperability and Prior Authorization Final Rule took effect for impacted payers (Medicare Advantage, Medicaid and CHIP managed care, federally facilitated Exchange plans). The rule mandates:

72h
Maximum decision time for standard prior-authorization requests, starting 2027
24h
Maximum decision time for expedited / urgent requests, starting 2027
FHIR
Required technical substrate for Patient Access, Provider Access, Payer-to-Payer, and Prior Authorization APIs

Translation: the days of faxing a prior-auth packet and waiting two weeks are ending. Every major payer and provider in the United States has to be exchanging prior-authorization data over FHIR-based APIs, with tight decision clocks, within the next eighteen months.

Prior authorization is already the single most-cited administrative pain point in American healthcare — by providers and by patients. Providers cite it as a top driver of burnout; patients cite it as the moment care stalls. The ePA rule is the federal response, and FHIR is the plumbing it runs on.

§ 03What "FHIR-native" actually means

Most health-tech companies were built before FHIR was a regulatory requirement. Their systems store data in proprietary schemas, and FHIR is something they translate to when asked — a mapping layer bolted onto an older core. That translation loses data, introduces errors, and limits how quickly new exchanges can be set up.

FHIR-native means the system stores, reasons about, and exchanges data in FHIR resources from the start. Every care-plan update, every observation from the home, every caregiver check-in — they all live as canonical FHIR objects. There is no translation layer, because there is nothing to translate from.

FHIR-translated

Data lives in a proprietary store; FHIR is a bolt-on.

  • Each new payer or EHR integration is a bespoke project
  • Translation drops or flattens clinical nuance
  • Prior-auth packets are rebuilt from scratch
  • Decision clocks are a stretch goal, not a default
FHIR-native (Dyad Health)

FHIR resources are the system of record.

  • New payer integrations stand up in days, not quarters
  • Clinical documentation never loses fidelity in transit
  • Prior-auth packets are assembled from canonical facts
  • Built for 24/72-hour decision clocks by default

§ 04Why this matters for prior authorization

The reason most prior-auth requests get denied, delayed, or sent back for more information is incomplete documentation on first submission. The referring provider submits what they have; the payer asks for what's missing; days pass; the patient waits. The industry average first-pass approval rate in complex populations is notoriously poor.

FHIR-native architecture changes the economics of the first submission, because the plan sees the full clinical picture — not a summary, not a PDF, but the structured resources that back it up. At Dyad Health we go one step further: every clinical documentation submission is evaluated by a former managed-care clinical reviewer before it leaves our system.

Those are the same people who used to sit on the other side of the desk, adjudicating these requests inside health plans. They know exactly what a complete packet looks like, because they spent their careers returning the incomplete ones. That pre-flight review, layered on top of FHIR-native data, is why our submissions clear first-pass at rates the legacy workflow can't match.

The compound effect. Complete clinical data, packaged in the canonical format the payer's system already expects, reviewed by a clinician who has adjudicated thousands of these requests. That's how decisions happen on the first pass — and how 24/72-hour clocks become routine, not heroic.

§ 05What this looks like in practice

i.
The home observation
A Dyad care navigator completes a home visit. The caregiver-burden score, a mood observation, a medication-adherence note, and a fall-risk assessment are captured directly into FHIR resources (Observation, CarePlan, RiskAssessment) on our platform.
ii.
The clinical synthesis
Those resources link to the member's existing FHIR record: active conditions, medication list, recent encounters, prior authorizations. The care team sees the household-level picture, not a single visit's snapshot.
iii.
The submission
When a service requires prior authorization — memory-care day program, home modifications, specialist referral — the packet is assembled from canonical FHIR resources. No rekeying, no PDF generation, no missing fields.
iv.
The pre-flight review
Before the submission leaves our system, a former managed-care clinical reviewer checks it against the exact payer criteria the adjudicator will use. If anything is thin, they fix it before it ships — not after it returns.
v.
The decision
The packet lands in the plan's utilization-management system over a FHIR API. The adjudicator sees structured data, complete on the first pass. The decision comes back inside the 24/72-hour window. The family gets care without the call-back loop.

§ 06Why this compounds for dementia care specifically

Dementia-affected dyads generate more prior-auth requests than almost any other population segment — memory-care day programs, home modifications, specialty pharmacy, behavioral consultations, skilled nursing stays, durable medical equipment, respite services. Every incomplete submission is a week of delayed care for two people, not one.

The same home-based, dyadic visibility that makes our clinical model work for the person with dementia is what makes our prior-auth submissions complete on first pass. That's not a coincidence; it's the same pipe serving two purposes.

§ 07Frequently asked

Does FHIR replace HL7 v2 and CCDA?
Over time, yes — but in practice health systems run all three in parallel. The ePA rule accelerates the FHIR-only timeline for prior authorization and interoperability APIs specifically; clinical messaging in other contexts continues to use v2 and CCDA alongside FHIR for the near term.
Which FHIR version does Dyad Health use?
HL7 FHIR R4, with the US Core Implementation Guide as our baseline profile set. For prior authorization specifically we conform to the Da Vinci PAS (Prior Authorization Support) and CRD (Coverage Requirements Discovery) implementation guides, which are the profiles CMS named in the ePA Final Rule.
Do providers have to change how they work to benefit from this?
No. Our FHIR exchange sits between the home-based care team and the health plan. Providers see Dyad's updates in their existing EHR through the standard FHIR integration their EHR vendor already offers. There is no new portal to log into, no duplicate documentation.
Who are the "former managed-care clinical reviewers" on your team?
Nurses and clinical pharmacists who spent part of their careers as utilization-management reviewers inside Medicare Advantage and dual-eligible plans. They know what complete documentation looks like because they spent years identifying what made submissions incomplete. They are employees of Dyad Health, reviewing our own submissions before they are sent to the payer.

§ 08Further reading

See how this works for providers →